Packet Forwarding Using Xen

Network virtualization allows the development of systems with several virtual routers (VR) over the same physical router. Each virtual router can execute, at the same time, different protocol stacks without disrupting the coexisting routers. The main purpose of this work is to analyze Xen capabilities and limitations and compare its efficiency with native solutions. Tests are performed in order to isolate possible bottlenecks and see how each mechanism provided by Xen can impact in performance. I. OVERVIEW Xen provides an architecture capable of supporting virtual routers. It offers an high flexibility framework to build virtualized systems, with the price of sacrificing some of its performance. In the Xen architecture, a layer called Virtual Machine Monitor (VMM) is spawned between the VRs and the real hardware. This layer is responsible for multiplexing the hardware access among all VRs, by the advent of an scheduler, that must decide which VR can access the hardware at each time. An abstraction of network access is created by a complex I/O mechanism. All these implementations are susceptible to bugs and misbehaviors that can lead to performance loss [2]. Xen architecture also includes a privileged virtual machine, called Domain 0, that has direct access to disk and network hardware and aids the VMM on I/O procedures. Domain 0 develops an important role in the behavior of the virtual routers, because it mediates the access between them and the real I/O device. II. TESTBED We develop a testbed to evaluate the performance of different forwarding elements. Our testbed is composed of a traffic generator machine (TG), a traffic receiver machine (TR) and a traffic forwarder machine (TF) that interconnects TG and TR. Tests are performed in order to compare TF forwarding performance running either Xen or native Linux. III. PARTIAL RESULTS The first performed test analyzes the influence of Xen mechanisms on the response time of TR. For different background traffic being forwarded by TF, we measure the round trip time (RTT) between TG and TR, with packets passing through TF. All configurations, i.e., native Linux and Domain 0 in bridged and routed modes, but the virtual router configuration show constant results (up to 0.25 ms). The maximum obtained RTT is 1.25 ms, achieved with background traffic of 500 Mb/s and 64-byte packets. This might seem a huge gap, but when we are aware that a 150 ms delay is fully acceptable in VoIP applications [1], we can see that this difference is not significant, even if there are more hops in the end-to-end path between TG and TR. The test performed in Fig. 1 aims at finding how forwarding is affected when Xen deals with parallel networks. We can see that there are two main bottlenecks in the Xen. The first one is the I/O mechanism that must combine CPU usage 0 50 100 150 200 250 1 2 4 8 A g g re g a te d p a c k e t ra te ( k p /s ) Number of parallel networks XenVM−1: One virtual machine per network XenVM−2 Native−Bridge Xen−Bridge